Method and system for dynamically and specifically targeting marketing

ABSTRACT

A rules evaluation engine operable to select optimal content for presentation to the viewer at each presentation opportunity. The engine evaluates segmentation rules associated with each particular content item in parallel, and then selects the best content to be presented. Priorities determined during evaluation sort out which content items will be presented. Real time dynamic enrichment of the decision making context occurs by retrieving additional information required to evaluate the rules. Logging and administrative processes for managing the segmentation rules are also realized.

RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S.Provisional Patent Application No. 60/482,487 entitled “System andMethod for Dynamically and Specifically Targeting Marketing,” filed onJun. 25, 2003, and is incorporated herein by reference in its entirety.This application is related to and incorporates by reference U.S.provisional application No. 60/438,972 filed Jan. 9, 2003 entitled,“Method and System for Dynamically Implementing an Enterprise ResourcePolicy”, and U.S. non-provisional application No. 10/755,173 filed Jan.9, 2004 entitled, “System and Method for Dynamically Implementing anEnterprise Resource Policy.”

TECHNICAL FIELD OF THE INVENTION

[0002] The invention relates to a system operable to select optimalcontent to be presented to a viewer, based upon both the characteristicsof the viewer and the viewing situation.

BACKGROUND OF THE INVENTION

[0003] Over the last decade, technology has drastically improved theeffectiveness of technology-based marketing. CRM systems have broughtbusinesses back to their ancestral roots by providing organizations witha collective memory of every customer and their interactions.Previously, this was cost-prohibitive.

[0004] However, providing the optimal message to a customer is still avery cumbersome and time-consuming process. As a result, corporationshave not fully benefited from the promise of real-time customized andpersonalized marketing. Many customized content and personalizationinitiatives remain undeveloped because of their prohibitive human andfinancial costs of implementation.

[0005] With the traditional targeted marketing paradigm, the sellerinitiates an interaction with the customer by analyzing historical datato segment customers offline and then “pushes” a message out to thecustomer. The seller then hopes for a response. However, other moreproactive methods are desired.

SUMMARY OF THE INVENTION

[0006] The present invention provides a system and method to select,from a predefined palette of content items, those items which are bestsuited for an individual. This selection is based both on the attributesof the viewer and the context in which the contents is viewed. (i.e., atthat precise moment in time). The content may involve advertisements,articles, or multimedia, such as animated images, movies, or audioclips.

[0007] More specifically, the present invention provides a centralizedsystem that defines and manages business rules to identify what contentis most relevant to the individual viewer's context. Then upon receiptof the content selection request, a centralized system evaluates theviewer's characteristics, the situational characteristics (context), andthe viewer's personal history against the coded rules in order to selectan optimal content set for display. Then the selected content isreturned to a local system that serves the selected content to theviewer. Essentially, a number of diverse content items can be managed bythe system, wherein each content item may have one or more coded ruleswhich define the viewer and content in which content would be presentedto the viewer.

[0008] In effect, each item of content has a rule which describes a“profile” of what an ideal viewer or presentation opportunity. When thecontent selection request is made, the coded rules associated with eachrelevant item are evaluated to determine if an appropriate viewingopportunity exists. If the rule is satisfied, the system then adds thecontent item, within a prioritized queue, to an aggregated body ofcontent items for this presentation opportunity. The items are thensorted, by descending priority, with the most significant items beingreturned for presentation. The prioritized list is returned based on theresults of evaluating the individual content items against variousbusiness rules. This produces a prioritized list of items most suitablefor presentation to the viewer in the viewer's current viewing context.

[0009] Several advantages are provided. First, the ability to performthe evaluation process in real time, at the moment of the request is asignificant advantage over existing systems. This allows the contentselected to be sensitive to the current presentation opportunity ratherthan the data warehouse intensive traditional model which selectscontent days, and even weeks, beforehand. The present invention may alsocouple to enterprise data sources, customer care systems, and externaldata sources such as credit scoring bureaus, etc. to provide a very richpalette of information on which to base the content selection rules.

[0010] A detailed log of each request made, along with any/all contentitems selected for presentation, provides for auditability andeffectiveness metrics, as well as inputs for a “feedback loop” in whichfuture presentation opportunities can be made based on prior decisions.For example, a rule could be constructed such that an individual item ofcontent would be highly prioritized under default conditions, but wouldbe deprioritized in favor of other content items after the original itemhad been presented to a viewer. One implementation may reduce an item'spriority after the item has been viewed three times in a 24-hour period.

[0011] An advantage of the present invention is that the rules definingthe optimal presentation opportunity do not need to be maintained inexecutable code by the administrator or user. The rules are captured ina representative notational format via a rule-builder GUI application,and then stored in an XML encoded structure within repository. As theyare not a part of the presentation engine (such as a web server), theycan be changed at will without the need to update or test the web serveror HTML source for the web pages the content is to be presented in. Theitems of content are managed in a hierarchical model, with each iteminheriting characteristics from its parent to determine who maymanipulate or change the rules which determine the rule's behaviorunless a specific rule is established for the individual item.Ultimately, this allows the rules to be administered in a distributedfashion throughout an enterprise, or even to clients (usuallyadvertisers) and business partners if the situation warrants such.

[0012] The invention can be invoked via a number of methods, including aJ2EE compliant API library, a procedural interface suitable for linkinginto legacy applications written in C, COBOL, FORTRAN, etc., a WebServices interface, a C+ interface, or even a custom-developed API foran individual customer's needs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] For a more complete understanding of the present invention andthe advantages thereof, reference is now made to the followingdescription taken in conjunction with the accompanying drawings in whichlike reference numerals indicate like features and wherein:

[0014]FIG. 1 depicts one basic implementation model to provide optimalcontent item for a particular viewer of a website;

[0015]FIG. 2 provides a logical flow diagram relating to processing acontent selection request;

[0016]FIG. 3 is a diagram of the Dynamically Expandable Rules Frameworkthat describes a process, implemented in code, by which invocation of aservice can be made both enabled for parallel scaling and tolerant offailure of components in accordance with the present invention;

[0017]FIG. 4 is a logic flow diagram providing a Dynamic EnrichmentProcess that depicts utilizing the rules engine to determine whether allof the data elements required to evaluate the rule are available; and

[0018]FIGS. 5A and 5B depict a Parallel Fault Tolerant Architecture thatenables the invention to dynamically scale effectively across multipleservers and/or platforms while continuously servicing requests from theusers/viewers.

DETAILED DESCRIPTION OF THE INVENTION

[0019] Preferred embodiments of the present invention are illustrated inthe FIGUREs, like numerals being used to refer to like and correspondingparts of the various drawings.

[0020] One potential architecture for the use with the invention isdepicted in FIG. 1. Here, user or viewer 10 requests a page of contentfrom web server 14. Viewer 10 may have previously established hisidentity by authenticating in some fashion with web server 14.Alternatively, viewer 10 may be treated as having a default or anonymousidentity.

[0021] Web server 14 loads page 13 from web page repository 12. Then webserver 14 executes java servlets or other like instructions that arecontained within page 13. The servlets invoke services applicationprogramming interface (API) which places a remote procedure call (RPC)into policy manager 16. This RPC requests content specifically chosenfor viewer 10. Request 11 contains both the identity of viewer 10 andinformation that defines the set of rules and content items to beselected from a campaign or set of related content items.

[0022] Policy manager 16 uses a name associated with the campaign or setof related content item to retrieve a set of rules 17 from rulesrepository 18. Policy manager 16 then examines rules 17 to determinewhat additional information or data elements are required to evaluaterules 17.

[0023] Policy manager 16 invokes any/all connectors required, includingbut not limited to LDAP connector 24, SQL DB connector 26 and customconnector 28 to retrieve the information or data elements required toevaluate rules 17. These data elements may be within directory database30, HR system database 32 and other data sources 34. These data sourcesreturn the data elements needed to policy manager 16.

[0024] Policy manager 16 enriches the decision context with theinformation retrieved. Policy manager 16 then evaluates the rules andcreates an aggregated list of the content items associated with any/allrules whose criteria are met. Policy manager 16 then sorts theaggregated list in order of descending priority. The top “n” items ofcontent (“n” being a number of items parameter passed on the ESAPIrequest), are selected and returned to web server 14 as the resultant ofthe ESAPI request. The web server then inserts those return contentitems into page 13, which may take the form of an HTML document. Thecustomized page is then presented to viewer 10 via a web browser orother like application.

[0025] Event log 36 may track every transaction created and storedwithin repository 38. The information within event log 36 can providethe basis of metrics determining system usage and effectiveness as wellas providing the inputs and capability on which to modify rules 17. Forexample, upon such information may include how many times a particularitem has been presented to a specific viewer in a defined time interval.

[0026]FIG. 2 provides a process flow diagram that depicts the logicalflow of web content request. The processing of a request to selectcontent items for a viewer. In step 50, viewer 10 establishes theiridentity by authentication through a means such as externalauthentication mechanism 51. Next, a request is sent to web server 55for a document in step 52.

[0027] In step 53, the document source is retrieved from the sourcerepository, whereupon the web server executes instructions embeddedwithin the document. Those instructions then invoke a services API instep 57 to request content from server 59. Optimal content is returnedto web server 59 in step 56. Instructions within the document are thenreplaced with content. Then in step 60, web server 55 delivers thecustomized page to the user's browser for display.

[0028]FIG. 3 depicts dynamically extensible rules management andevaluation framework 70. Rules evaluation engine is based upon theconcept of using a process by which a policy is expressed as a rule,encoded in a machine-independent rules modeling language. The rule canbe dynamically loaded from the repository 72 and evaluated upon demandwithin multiple execution contexts simultaneously. This provides forparallel scaling and fault tolerant capabilities. As the rules areloaded dynamically at evaluation time, rules may be created and/orchanged at will, and will take effect upon the next evaluation request.

[0029] In FIG. 3, GUI 74 allows administrative users to access rules 17stored within repository 72. GUI 74 also facilitates the ability ofadministrative users to create and modify coded rules based on businessrules. GUI 74 interacts with repository 72 through server 76. The codedrules corresponding to the business rules are stored within repository72. These rules 17 determine what content will be eligible to bepresented to a viewer as previously described in FIGS. 1 and 2.

[0030] Rules 17 are retrieved from repository 72 following receipt of acontent selection request that corresponds to query 78 that is receivedvia web server 14 via input from user 10 through web server 14. Rules 17are dynamically loaded and interpretively evaluated within process 82wherein the results of this evaluation are returned to web server 14 orother requesting application in order to present the optimum content toa viewer.

[0031] The concept of dynamic enrichment of the data is available withinthe decision context depicted in FIG. 4. The dynamic enrichment processinvolves receiving a request in step 80. In step 82, in response to therequest, a policy set is loaded from repository in step 82. The policyset is analyzed to determine the required data elements in step 84. Instep 86, metadata is consulted and data elements are grouped byconnector. For each connector a determination is made in step 88 fordata for each data element within the connector. This involvesdetermining whether or not each data element already has a value atdecision point 90. If it does, an evaluation is made for the next dataelement. If not, a determination is made a decision point 92 as towhether or not all required key values for this data element arepresent. If all the required key values for this data element arepresent the data element is added to the connector request in step 94,otherwise, a determination is made for the next data element. Indecision point 96, a determination is made as to whether or notadditional data elements are required for this data connector. Ifadditional elements are required the next data element is evaluatedreturning to step 96. Otherwise, at decision point 98, a determinationis made as to whether or not any more connectors remain to be processed.Additional connectors are processed as described above. Otherwise, theconnectors with unresolved elements are invoked at step 100 in order toretrieve identified additional data elements. At decision point 102, adetermination is made as to whether or not any new values wereretrieved. If there were, at decision point 104, a determination is madeas to whether any unfilled data elements remain in which case theprocess is repeated by returning to step 88 until no unfilled dataelements remain as indicated at point 106. Essentially, feature allowsthe rules engine to determine when all the data elements required toevaluate the policy are present. If the answer is no, then the rulesengine may, through connectors, map to and retrieve all requisite dataelements before evaluating the rule.

[0032] A diverse, fault tolerant architecture that enables effectivelysealing across multiple servers and/or platforms while continuouslyservicing content selection requests is depicted in FIGS. 5A and 5B.This architecture effectively operates even when a multiple server lossoccurs.

[0033]FIG. 5A depicts the process of realm startup. At step 120, therealm startup process is initiated. In step 122, all of theconfiguration files are read and associated processes are initiated.These processes are all registered with the service registry in step 124after which the monitor performs regular health checks at predeterminedintervals in step 126. If a dead process is found, the monitor deletesthe registry and restarts the process in step 128.

[0034]FIG. 5B depicts client side fault tolerant wrapper logic. Here, instep 130 a client API wrapper is invoked. At decision point 132, adetermination as to whether or not local cache of handles is requiredfor service. If not required for service, the service handles areretrieved in step 134. Otherwise, a random handle is selected from anavailable list in step 136. Returning to retrieving service handles,decision point 138 evaluates whether or not handles were retrieved. Ifthey were not, a return failure is made to the user in step 140.Otherwise, we progress to step 136 where the random handles are selectedfrom the list. In step 142, a service call is initiated, after which atdecision point 144, a determination is made as to whether or not acommunication failure is indicated. If no communication failure isindicated, the resultant is returned to the user in step 146. Otherwise,the monitor is notified of failed service. In step 148, the dead handlesare removed from the registry and reinitiating begins in step 150, afterwhich the process returns to step 134.

[0035] The current implementation of this concept is built upon a Javainfrastructure, and utilizes a number of fairly obscure features of theJava language to facilitate the service. The two most prominent of theseare the concept of a dynamic class loader, and HTTP/XML RPC architectureused to manage the interaction between processes.

[0036] It is important to note that while one embodiment is implementedin the Java language, the concepts that distinguish the presentinvention are notably not Java specific, and in no way should the claimsbe restricted to the Java language or the platforms on which it runs. Ina procedural language such as C/C++, PL/1, etc. the same concepts couldreadily be implemented through the use of dynamically shared librariesor through dynamic overlay methods that are well defined andcommonplace.

[0037] While the embodiments discussed above focus on serving content toa web server, the present invention may also service other deliverymechanisms such as a Voice Response Unit (VRU), a wireless device suchas a pager or cell phone, etc.

[0038] Although the present invention is described in detail, it shouldbe understood that various changes, substitutions and alterations can bemade hereto without departing from the spirit and scope of the inventionas described by the appended claims.

What is claimed is:
 1. A centralized system to select particular contentitems to be presented to a viewer from a plurality of content items,comprising: a coded rule associated with each particular content item; aserver operable to: receive a content selection request; execute a rulesengine, wherein the rules engine is operable to evaluate a plurality ofcoded rules in parallel, in order to determine particular content itemsthe viewer is eligible to receive in response to the content selectionrequest; support a graphical user interface (GUI) operable to facilitatebuilding and managing the coded rules; maintain an application programinterface (API) library operable to manage communications between arequesting service and the rule engine; interface with an informationretrieval facility operable to retrieve information required to evaluatethe coded rules; and maintain an integrated usage and audit log operableto provide metrics and a feedback process, wherein the integrated usageand audit log allow the coded rules to be dependent upon prior behaviorsof the viewer.
 2. The centralized system of claim 1, wherein the serveris further operable to log and track each content selection request. 3.The centralized system of claim 1, wherein the server is furtheroperable to: determine additional information required to evaluate thecoded rules; locate the additional information required to evaluate thecoded rules; extract the additional information required to evaluate thecoded rules; and retrieve the additional information required toevaluate the coded rules.
 4. The centralized system of claim 3, whereinthe server evaluates the content selection requests in real time withthe additional information required to evaluate the coded rules.
 5. Thecentralized system of claim 1, wherein the coded rules associated withthe content selection request are operable to be updated and immediatelyactivated.
 6. The centralized system of claim 5, wherein ownership ofthe coded rule associated with the content selection request hasdistributed administrative ownership and control.
 7. The centralizedsystem of claim 1, wherein the server is further operable to generate analarm based upon the evaluation of the user request in real time,wherein the alarm is sent to an appropriate location.
 8. The centralizedsystem of claim 1, wherein a rule repository is operable to store thecoded rules.
 9. A method to select particular content items to bepresented to a viewer from a plurality of content items, comprising:receiving a content selection request for content items to be presentedto a viewer from a requesting system; identifying the viewer with anauthenticated identity or an anonymous identity associated with thecontent selection request; retrieving a coded rule associated with thecontent selection request corresponding to a set of related contentitems; determining data elements required to evaluate the contentselection request; retrieving the identified data element required toevaluate the content selection request; evaluating the content selectionrequest in real time; prioritizing the resultant set of content items;and providing a prioritized list of the resultant set of content itemsto the requesting system.
 10. The method of claim 9, further comprising:logging each content selection request; tracking each content selectionrequest; logging each data elements required to evaluate each contentselection request; and tracking each data elements required to evaluateeach content selection request.
 11. The method of claim 9, whereinprioritizing the resultant set of content items comprises ranking of theresultant set of content items by at least one means selected from thegroup consisting of predefined static priorities, correlation tostatistical models, derived priorities set by external data interfaces,and priorities modified by rules-based exclusivity orrandom-distribution operations.
 12. The method of claim 9, wherein thecoded rules are created and deployed with a graphical user interface(GUI), wherein the GUI allows an administrator to specify business rulesthat determine content presentation eligibility.
 13. The furthercomponent of claim 9, further comprising updating the coded rules basedon an intelligent feedback process in which the results andeffectiveness of individual and/or aggregate presentations of selectedcontent items are analyzed to refine the coded rules.
 14. The method ofclaim 9, further comprising: determining additional data elementsrequired to evaluate content selection request against the coded rules;locating the additional data elements required to evaluate the contentselection request against the coded rules; extracting the additionaldata elements required to evaluate the content selection request againstthe coded rules; and retrieving the additional data elements required toevaluate the content selection request against the coded rules.
 15. Themethod of claim 14, further comprising evaluating the content selectionrequest in real time with the additional data elements.
 16. The methodof claim 9, wherein the coded rules associated with a campaign definedin the content selection request are capable of being modified andimmediately implemented.
 17. The method of claim 16, wherein ownershipof the coded rules associated with the campaigns and content items hasdistributed administrative ownership and control.